home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9609 / 000001_owner-urn-ietf _Mon Sep 2 16:44:02 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA10787 for urn-ietf-out; Mon, 2 Sep 1996 16:44:02 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA10782 for <urn-ietf@services.bunyip.com>; Mon, 2 Sep 1996 16:44:00 -0400
  3. Received: from rock.west.ora.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA15164  (mail destined for urn-ietf@services.bunyip.com); Mon, 2 Sep 96 16:43:56 -0400
  5. Received: (from terry@localhost) by rock.west.ora.com (8.6.13/8.6.11) id NAA20398 for urn-ietf@bunyip.com; Mon, 2 Sep 1996 13:41:41 -0700
  6. Message-Id: <199609022041.NAA20398@rock.west.ora.com>
  7. From: Terry Allen <terry@ora.com>
  8. Date: Mon, 2 Sep 1996 13:41:41 PDT
  9. X-Mailer: Mail User's Shell (7.2.0 10/31/90)
  10. To: urn-ietf@bunyip.com
  11. Subject: [URN] Re URN concerns
  12. Sender: owner-urn-ietf@services.bunyip.com
  13. Precedence: bulk
  14. Reply-To: Terry Allen <terry@ora.com>
  15. Errors-To: owner-urn-ietf@bunyip.com
  16.  
  17. [lost my electronic copy, so typed in the quotes from printed version]
  18.  
  19. Karen Sollins writes:
  20. "I have a couple of concerns ...  It seems that in discussion, whether
  21.  or not in the text of the documents, the authors of the NAPTR framework
  22.  and proposal papers want to provide resolution for all possible 
  23.  namespace schemes."
  24.  
  25. I hope so.  That is the problem as I see it.  Karen continues:
  26.  
  27. "Perhaps we would all be better off and have a higher probability of
  28.  success, if we identified a smaller set of namespaces to which we 
  29.  were addressing out attention."
  30.  
  31. I don't see where there is lack of success brewing.  
  32.  
  33.  - It is up to namespace resolvers to resolve URNs to something else
  34.    such as URLs.  The NAPTR scheme can't guarantee that will happen,
  35.    only that the client gets pointed at the right resolver.
  36.  
  37.  - You can make a more elegant solution by restricting the problem,
  38.    but then you haven't solved the real problem.  Suggestions for
  39.    how to create easily manageable name spaces are worth making,
  40.    but people will do what they will do.  Restricting the namespaces
  41.    that the point-client-toward-resolver mechanism can use fails to
  42.    solve the real world problem, and guarantees that the solution
  43.    will fail to cover all real world cases, making it useless.
  44.  
  45.  - Instead of viewing opaque strings as a problem, it would be useful
  46.    to accept that they exist and can be exploited; regexps (funky though
  47.    they are) appear to this lost soul to be a way to exploit info that
  48.    may be known to reside in opaque strings.
  49.  
  50.  - It's time to get the show on the road.  I am looking forward to being
  51.    able to provide hands-off resolution of Docbook DTD entities using
  52.    NAPTR and the Docbook FPIs.  When ANSI appoints a formal registration
  53.    authority (currently thought to be the Graphic[al]? Communications
  54.    Association, GCA), the registry that GCA has already set up can point
  55.    to the Davenport site, which already exists, and we can resolve FPIs
  56.    both registered and unregistered.  Talking about how it would be
  57.    nicer if we could constrain how naming schemes work is unrealistic
  58.    (we can't, and no one has offered a counterargument that we can), and 
  59.    dilatory.
  60.  
  61.    Beyond that, SGML *is* coming to the Internet, and fairly soon.  Modern
  62.    SGML entity resolution depends on FPIs and catalogues containing them.
  63.    FPIs are made up by humans, and beyond the owner identifier and the
  64.    (nonhierarchically placed) field indicating (uselessly) whether an FPI
  65.    applies to an element, entity, DTD, etc., there is a lot of opportunity
  66.    (which has already been taken advantage of) for messiness.  
  67.  
  68.    There is thus a practical need to be able to resolve any FPI anyone
  69.    may assign or has already assigned.  Constraining FPI construction
  70.    beyond the rules in (I believe) ISO 9070 is a nonstarter.
  71.  
  72.  
  73.  
  74.  
  75. Regards,
  76.  
  77. -- 
  78.        Terry Allen      O'Reilly & Associates, Inc.   terry@ora.com
  79.  "In going on with these experiments, how many pretty systems do we build,
  80.   which we soon find ourselves obliged to destroy?"  -  Benjamin Franklin
  81.         A Davenport Group sponsor     http://www.ora.com/davenport/